Skip to content

WIP ROX-33217: Instrument inode tracking on directory being created#449

Draft
JoukoVirtanen wants to merge 20 commits intomainfrom
jv-ROX-instrument-inode-tracking-on-directory-being-created
Draft

WIP ROX-33217: Instrument inode tracking on directory being created#449
JoukoVirtanen wants to merge 20 commits intomainfrom
jv-ROX-instrument-inode-tracking-on-directory-being-created

Conversation

@JoukoVirtanen
Copy link
Copy Markdown
Contributor

@JoukoVirtanen JoukoVirtanen commented Mar 30, 2026

Description

Directory creation events need to be handled correctly. When a directory is created in a tracked directory its inode should be added to a hash set in kernel space. In user space an entry needs to be added into a map with the inode as the key and file path as the value.

A downside of this approach is that it does not currently handle recursive cases, though I believe that this can be overcome.

I tried a few alternatives.

I started out trying to use a path_mkdir LSM hook, but as the design document suggested, it doesn't have the new inode. So, I tried tracepoints on the mkdir and mkdirat syscalls, which the design document suggested as an alternative. Neither of them worked. I also tried an LSM hook on inode_mkdir, that didn't work either.

Checklist

  • Investigated and inspected CI test results
  • Updated documentation accordingly

Automated testing

  • Added unit tests
  • Added integration tests
  • Added regression tests

If any of these don't apply, please comment below.

Testing Performed

CI is sufficient.

// x86_64 -> x86, aarch64 -> arm64
let bpf_arch = match cargo_arch.as_str() {
"x86_64" => "x86",
"aarch64" => "arm64",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are need because of

  args.dir = (struct inode*)PT_REGS_PARM2_CORE(ctx);
  args.dentry = (struct dentry*)PT_REGS_PARM3_CORE(ctx);

Which expects __TARGET_ARCH_x86 or __TARGET_ARCH_arm64 instead of __TARGET_ARCH_x86_64 or _TARGET_ARCH_aarch64. Currently both versions are used. One for PT_REGS_PARM2_CORE and one for fact-ebpf/src/bpf/vmlinux.h. Perhaps that file could be edited to use __TARGET_ARCH_x86 or __TARGET_ARCH_arm64. I don't know if that would cause other problems.

}

__always_inline static struct bound_path_t* _path_read(struct path* path, bound_path_buffer_t key, bool use_bpf_d_path) {
__always_inline static struct bound_path_t* _path_read(const struct path* path, bound_path_buffer_t key, bool use_bpf_d_path) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found that I needed to cast from const in one place, so I changed some function signatures to take in const to avoid that. I ended up using a cast from const in fact-ebpf/src/bpf/d_path.h anyways. I will likely change these back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant